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What  we’ll  discuss  today 

Quality  Attributes 

Eliciting  Quality  Attribute  Requirements 
Quality  Attribute  Workshop 
Quality  Attribute  Scenarios 


r  i 

I’ll  take  questions  at  the  end  of  the  presentation. 
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Polling  Question 


When  is  the  best  time  to  specify  quality  attribute 
(non-functional)  requirements? 

1 .  After  the  software  architecture  is  established 

2.  Before  the  software  architecture  is  established 

3.  Quality  attributes  are  not  important 
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What  are  Quality  Attributes? 

Measurable  or  testable  properties  of  a  system  used  to  indicate 
how  well  the  system  satisfies  the  needs  of  its  stakeholders 

Here  are  some  examples  of  quality  attributes: 

•  availability 

•  configurability 

•  modifiability 

•  performance 

•  reliability 

•  reusability 

•  security 

•  throughput 
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Stakeholders  and  Quality  Attributes 


Stakeholder 

Needs 


“Increase  market  share”  - 

“Maintain  a  quality  reputation”  — 
“Introduce  new  capabilities  seamlessly” 
“Provide  a  programmer-friendly  framework” 
“Integrate  with  other  systems  easily” 


Quality  Attribute 
Requirements 

- _>  Modifiability,  Usability 

-  ->  Performance,  Usability,  Availability 
■>  Performance,  Availability,  Modifiability 

-* - - - >  Modifiability 

>  Interoperability,  Portability,  Modifiability 
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Quality  Attributes  and  Architecture 


The  degree  to  which  a  system  satisfies  quality  attribute  requirements  is 
directly  dependent  on  architectural  structure. 


Quality  Attribute 
Requirements 


Software  Architecture 
Design 


Consequently ,  architects  need  to  have  a  solid  understanding  of  the  quality 
attribute  requirements  for  a  system  when  they  are  designing  the  system’s 

software  architecture. 
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Polling  Question 

What  approach  does  your  organization  use  to  specify 
quality  attribute  requirements? 

1 .  We  ask  management  what  they  think  the  system  should  do. 

2.  We  discuss  the  system’s  quality  attributes  once  the  system 
is  designed. 

3.  We  use  a  method  to  gather  the  views  of  all  our  stakeholders 
early  in  the  development  life  cycle. 

4.  We  don’t  worry  about  quality  attributes. 
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Eliciting  Quality  Attribute  Requirements 


Eliciting  Eliciting 

ltoli(tlieBalaB3qait6ciatitiJ)s  quality  attribute 

sanrdhDjtesQ&iradoQteSrgrrtts  requirements 

I  1 

Good  Job  Bad  Job 
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Problems  With  Quality  Attribute  Requirements 


Non-Operational  requirements 

•  “The  system  must  be  easy  to  use.” 

•  “The  system  must  have  high  performance.” 

•  “The  system  must  be  portable.” 

Debating  the  quality  attribute  to  which  a  system  behavior  belongs 

•  “The  system  must  process  10,000  messages  per  second.” 

Vocabulary  variations 

•  Everyone  knows  what  “high  performance”  means,  right? 
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Quality  Attribute  Workshop  (QAW) 


Facilitated  method 

•  system-centric 

•  used  before  the  software  architecture  has  been  created 

Engages  system  stakeholders  early  in  the  life  cycle 

Reveals  the  driving  quality  attribute  requirements  of  a  software-intensive 
system 

•  scenario  based 


A  QAW  delivers  the  quality  attribute  requirements  for  the  system , 
documented  as  refined  and  prioritized  quality  attribute  scenarios 

The  quality  attribute  scenarios  can  then  be  used  as  the  basis  for 
designing  the  software  architecture  for  the  system. 
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QAW  Steps 


1 .  QAW  Presentation  and  Introductions 

2.  Business/Programmatic  Presentation 

3.  Architectural  Plan  Presentation 

4.  Identification  of  Architectural  Drivers 

5.  Scenario  Brainstorming 

6.  Scenario  Consolidation 

7.  Scenario  Prioritization 

8.  Scenario  Refinement 
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QAW  Steps 


1 .  QAW  Presentation  and  Introductions 

2.  Business/Programmatic  Presentation 

3.  Architectural  Plan  Presentation 

4.  Identification  of  Architectural  Drivers 

5.  Scenario  Brainstorming 

6.  Scenario  Consolidation 

7.  Scenario  Prioritization 

8.  Scenario  Refinement 


Today’s  focus 
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Step  4:  Identification  of  Architectural  Drivers 

The  QAW  facilitators  identify  the  architectural  drivers  that  are  key  to 
realizing  quality  attribute  goals  by 

•  presenting  a  distilled  list  of  the  architectural  drivers  they  heard  during 
the  Business/Programmatic  and  Architecture  Plan  presentations 

•  asking  for  clarifications,  additions,  or  deletions  to  reach  a  consensus 
on  the  architectural  drivers 


The  final  list  of  architectural  drivers  focuses  the  stakeholders 

during  scenario  brainstorming. 

L _ Jk 
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Step  5:  Scenario  Brainstorming 

Stakeholders  generate  scenarios  using  a  facilitated  brainstorming  process. 

Each  stakeholder  either  generates  a  scenario  in  round-robin  fashion  or 
opts  to  pass. 

Each  stakeholder  may  have  an  opportunity  to  contribute  more  than  one 
scenario,  depending  on  the  number  of  stakeholders  in  the  QAW  and  the 
allocated  time  for  the  workshop. 
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Step  5:  Scenario  Brainstorming 


Scenario  brainstorming  guidance 


•  Quality  attribute  requirements  are  most  effectively 
characterized  vis-a-vis  scenarios. 

•  Scenarios  are  “short  stories”  that  describe  a  system 
interaction  with  respect  to  some  quality  attribute. 

•  Well-formed  scenarios  have  a  stimulus,  an  environ¬ 
ment,  and  a  response. 

•  The  QAW  focuses  on  three  kinds  of  scenarios: 

•  use  case  -  anticipated  uses  of  the  system 

•  growth  -  anticipated  changes  to  the  system 

•  exploratory  -  unanticipated  stresses  to  the  system 
(uses  and/or  changes) 
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Stimuli,  Environment,  Responses 


Use  case  scenario 

A  remote  user  requests  a  database  report  via  the  Web  during  a  peak 

period  and  receives  it  uithin  5  seconds. 


Growth  scenario 

Add  a  new  data  server  to  reduce  latency  in  the  use  case  scenario  to 
2.5  seconds  uithin  1  person-ueek. 

Exploratory  scenario 

Half  of  the  servers  go  down  during  normal  operation  u;  1 1  h  o  u  t 

affecting  overall  system  avai labi 1 i ty. 
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Step  6:  Scenario  Consolidation 


The  QAW  facilitators  ask  stakeholders  to  identify  those  scenarios  that 
are  very  similar  in  content. 

•  Similar  scenarios  are  merged  to  prevent  a  “dilution”  of  votes  when 
voting  is  done  in  the  next  step. 

•  QAW  facilitators  attempt  to  reach  a  consensus  with  the  stakeholders 
before  merging  scenarios. 
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Step  6:  Scenario  Consolidation 


Example  of  scenario  consolidation 


Scenarios  that  are  similar  in  content  are  grouped  together. 

•  In  the  event  of  a  processor  fault,  the  system  can  be 
rebooted/reinitialized. 

•  A  processor  failure  or  crash  doesn’t  adversely  affect  any 
other  components  (no  second-order  failures). 

•  Software  continues  to  operate  even  if  the  host  fails 
(mission  computer). 
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Step  7:  Scenario  Prioritization 


Each  stakeholder  is  allocated  a  number  of  votes  equal  to  approximately 
30%  of  the  number  of  scenarios  generated. 

•  The  actual  number  of  votes  allocated  to  stakeholders  is  rounded  up  to 
an  even  number  of  votes. 

•  Voting  occurs  in  two  rounds  where  each  stakeholder  allocates  exactly 
half  of  his  or  her  total  votes  in  each  round. 

•  Stakeholders  can  allocate  any  number  of  votes  to  any  scenario  they  like. 

•  Votes  are  counted,  and  the  scenarios  are  prioritized  accordingly. 
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Step  8:  Scenario  Refinement 


The  top  scenarios  are  further  refined. 

•  Typically,  the  top  five  scenarios  are  refined,  but  the  exact  number  will 
depend  on  the  time  available. 

The  QAW  facilitators  further  elaborate  each  scenario  and 

•  document  the  business/programmatic  goals  affected  by  the  scenario 

•  describe  the  relevant  quality  attributes 

•  rephrase  it  in  six  parts:  a  stimulus,  a  stimulus  source,  an  environment, 
an  artifact,  a  response,  and  a  response  measure 

•  document  a  list  of  related  questions  that  stakeholders  want  to  ask 

•  document  any  issues  that  may  arise  during  scenario  refinement 
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Example  Scenario  Refinement  - 1 


Scenario 

The  track  capacity  is  saturated  during  peak 
operations  over  a  large-sized  theatre  and  degrades 
in  a  predictable  and  useful  manner. 

Business  Goals 

Mission  effectiveness 

Quality  Attributes 

•  performance 

•  scalability 
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Example  Scenario  Refinement  -  2 


Stimulus 

Some  resource  capacity  is  saturated 
(or  hits  high  watermark). 

Stimulus  Source 

Network,  memory,  applications,  and  so  on 

Environment 

Operational  with  high  load  conditions 
(or  battle  damage) 

Artifact 

Track  Manager  or  host  system 

Response 

•  throttling  appropriately 

•  request  for  or  release  of  resources 

Response 

Measure 

Predictable  behavior  as  appropriate  per  platform 
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Example  Scenario  Refinement  -  3 


Questions 


What  is  the  track  capacity?  Is  it  based  on 
hardware?  How  do  you  know  it’s  saturated? 

In  what  ways  can  you  degrade  the  quality  of 
service  associated  with  the  tracks? 

What  can  be  automated? 

Which  architectural  decisions  apply  and  support 
that  automation? 

Which  degrade  modes  do  stakeholders  want  to 
see  implemented? 
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Example  Scenario  Refinement  -  4 


Issues 


We  can’t  size  systems  a  priori  to  eliminate 
oversaturation. 

Track  Manager  needs  a  way  to  compensate  for 
saturation  in  a  doctrinally  appropriate  manner. 

Open  a  dialogue  with  the  applications  using 
Track  Manager  to  identify  objects  of  interest, 
so  that  applications  can  have  a  say  in  this  answer. 
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For  More  Information 


Contact  me  at 


Rob  Wojcik 

rwoicik@sei.cmu.edu 


•  Find  out  more  about  the  QAW: 

www.sei.cmu.edu/architecture/tools/establish/qaw.cfm 


For  more  about  the  SEI  approach  to  quality  attributes 
and  architecture-centric  engineering,  start  exploring  at 

www.sei.cmu.edu/architecture/ 


Also  see  Software  Architecture  in  Practice,  3rd  edition 
written  by  Len  Bass,  Paul  Clements,  &  Rick  Kazman  and 
published  by  Addison-Wesley  as  part  of  the  SEI  Series  in 
Software  Engineering. 

Visit  www.sei.cmu.edu/librarv/abstracts/books/9780321 81 5736.cfm 
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